1.1.1. Vendor 1

Vendor 2 server worked well with Vendor 1. We had some trouble at first with recurring meetings, but that was resolved server-side. The only part of the interop that didn’t end in an outright “Pass” was the use of the inbox, since the server uses a “virtual” inbox and doesn’t actually create and store messages in it. Either way, this didn’t really have any impact on Vendor 1. The auto-scheduling was working nicely.

Vendor 1 vs. Vendor 5:

We had some initial issues where the server did not adhere to various elements of the WebDAV/CalDAV spec, which caused problems with loading the account into Vendor 1. I hacked around that on the client side in order to test and reported the issues to Vendor 5, but that will need to be fixed server-side before it will work with stock Vendor 1.

Vendor 1 encountered many 500 errors from the server, so testing was limited by that. The server was continually setting the organizer’s attendee to RSVP=TRUE, which caused display issues in Vendor 1. The server also stripped all but display alarms. Free-busy lookups did work well, though.

Vendor 1 vs. VENDOR 3:

500 errors when adding alarms or attendees prevented much of the tests in the matrix.

Table 2 — Vendor 1 client testing matrix results chart

Servers					Comments
Vendor 2	Vendor 5	VENDOR 3
			1.	Event creation.
P	P	P	1.1.	Create new single-instance meeting titled “Meeting 1.1” with the location “Durham”.	Vendor 5: setting organizer’s attendee to `RSVP=TRUE` causes display weirdness in Vendor 1
P	P	P	1.2.	Create new meeting titled “Meeting 1.2” recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks.
P	P	F	1.3.	Create new single-instance meeting titled “Meeting 1.3” with 2 other attendees.
P	P/F	F	1.4.	Create new single-instance meeting titled “Meeting 1.4” with an alarm set to trigger 15 minutes prior to the schedule time of the meeting.	Vendor 5: only `DISPLAY` alarms remain, all others are stripped
			2.	Event modification
P	P/F	P	2.1.	Modify the title of meeting “Meeting 1.1” to “Meeting 1.1bis”.	Vendor 5: sometimes it worked, sometimes it failed.
P	P/F	P	2.2.	Modify the location of the meeting “Meeting 1.1bis” to “Seattle bis”.	Vendor 5: see 2.1
P	P	P	2.3.	Reschedule meeting “Meeting 1.1bis” to the next day.
P	P	F	2.4.	Add an attendee to “Meeting 1.1bis”.
P	P	F	2.5.	Add an alarm to “Meeting 1.1bis”.
P	F	P	2.6.	Modify the title of the 1st instance of the recurring meeting created in 1.2.
P	P	F	2.7.	Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`.	VENDOR 3: cannot add attendees
P	P	P	2.8.	Cancel the 4th instance of the recurring meeting created in 1.2.
P	P	F	2.9.	One client changes “Meeting 1.1bis” to a different time, second client ‘refreshes’ its display to see the modification.	VENDOR 3: see 1.3, 2.7
			3.	Event retrieval
N	N	N	3.1.	calendar-query `REPORT`	Vendor 1 does not implement calendar-query `REPORT`
			3.1.1.	No filtering (match everything)
			3.1.1.1.	Query all components and return all data. (tests <calendar-query> and <filter>)
			3.1.1.2.	Query all components and return ETag WebDAV property and all data. (tests `<calendar-query>+<DAV:prop>` and `<filter>`)
			3.1.1.3.	Query all components and return just entire `VEVENT` components. (tests `<calendar-query>, <filter>+<comp-filter>`)
			3.1.1.4.	Query all components and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests `<calendar-query>`, <filter><comp-filter>`, `<calendar-data><comp>+<prop>)
			3.1.2.	time-range filtering
			3.1.2.1.	Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests `<calendar-query>`, `<filter>+<time-range>`)
			3.1.2.2.	Query all components within a one week time-range and return just entire `VEVENT` components. Make sure that there is a recurring event that starts prior to the chosen time-range but has one overridden instance within the time-range. (tests `<calendar-query>`, `<filter>+<time-range>`)
			3.1.3.	component based filtering
			3.1.3.1.	Query all components that contain an embedded `VALARM` component. (tests `<calendar-query>`, `<filter>+<comp-filter>`)
			3.1.3.2.	Query all components that contain an embedded `VALARM` component whose trigger falls within a specific time-range. (tests `<calendar-query>`, `<filter><comp-filter><prop-filter>+<time-range>`)
			3.1.4.	property based filtering
			3.1.4.1.	Query all components that contain any `ORGANIZER` property. (tests `<calendar-query>`, `<filter><prop-filter><is-defined>`)
			3.1.4.2.	Query all components that contain an `ORGANIZER` property with a specific CUA text value case-insensitively. (tests `<calendar-query>`, `<filter><prop-filter><text-match>+<caseless>`)
			3.1.4.3.	Query all components that contain an `ORGANIZER` property with a specific CUA text value case-sensitively. (tests `<calendar-query>`, `<filter><prop-filter><text-match>+<caseless>`)
			3.1.5.	parameter based filtering
			3.1.5.1.	Query all components that contain a `DTSTART` property with a `TZID` parameter. (tests `<calendar-query>`, `<filter><prop-filter><text-match><param-filter><is-defined>`)
			3.1.5.2.	Query all components that contain an `ATTENDEE` property with `PARTSTAT=NEEDSACTION` parameter. (tests `<calendar-query>`, `<filter><prop-filter><text-match><param-filter><text-match>`)
			3.2.	calendar-multiget `REPORT`
			3.2.1.	Query a specific `href` and return all data. (tests `<calendar-multiget>`)
			3.2.2.	Query multiple `href`s (some of which do not exist) and return all data. (tests `<calendar-multiget>`)
			3.2.3.	Query a specific `href` and return ETag WebDAV property and all data. (tests `<calendar-multiget>+<DAV:prop>`)
			3.2.4.	Query multiple `href`s (some of which do not exist) and return ETag WebDAV property and all data. (tests `<calendar-multiget>+<DAV:prop>`)
			3.2.5.	Query a specific `href` and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests `<calendar-query>`, `<calendar-data><comp><prop>`)
			3.2.6.	Query multiple `href`s (some of which do not exist) and return `VEVENT` components with only `DTSTART`, `DTEND/DURATION`, `SUMMARY`, `UID`, `SEQUENCE`, `RRULE`, `RDATE`, `EXRULE`, `EXDATE`, `RECURRENCE-ID`. (tests `<calendar-query>`, `<calendar-data><comp><prop>`)
			4.	Event deletion
P	P	P	4.1.	Delete a single non-recurring meeting.
P	P	P	4.2.	Delete a single recurring meeting with no overridden instances.	Vendor 2: 4.2-4.5 originally failed but server changes made during meeting led to success.
P	F	P	4.3.	Delete a single recurring meeting with overridden instances.
P	F	P	4.4.	Delete a non-overridden instance of a recurring meeting.
P	F	P	4.5.	Delete an overridden instance of a recurring meeting.
			5.	Access Control
N	N	N	5.1.	View access control details on current user’s main calendar.
N	N	N	5.2.	Change access control details on current user’s main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it.
N	N	N	5.3.	Change access control details on current user’s main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other.
N	N	N	5.4.	Remove another user’s access to the current user’s main calendar and verify they can no longer access the calendar.
			6.	Calendar Management
P	P	P	6.1	Browse the list of calendars on the server, including the current user’s personal calendars.
P	F/N	F	6.2	Create a new calendar in the current user’s personal calendar space.	Vendor 5: does not support this
N	N	N	6.3	Create a regular collection in the current user’s personal calendar space.	Vendor 1 does not implement creation of regular collections.
N	N	N	6.4	Create a new calendar inside the collection created in 6.3.
P	N	F	6.5	Delete the calendar created in 6.2.
N	N	N	6.6	Delete the collection created in 6.3.
			7.	Free Busy Reports
			Setup	Create a new calendar and populate it with the following for one week: Event on Monday, 9 am — 11 am, recurs every day for five times Event on Monday, 12 pm — 1 pm, status tentative Event on Monday, 2 pm — 3 pm, status cancelled Event on Tuesday, 11 am — 12 pm Event on Tuesday, 2 pm — 4 pm, recurs every day for four times Event on Tuesday, 3 pm — 5 pm Event on Wednesday, 11 am — 12 pm, status tentative Event on Wednesday, 3 pm — 5 pm, status tentative Event on Thursday, 11 am — 12 pm, status cancelled Event on Thursday, 3 pm — 5 pm, status cancelled	Note 1 Vendor 1 does not differentiate between tentative and unavailable in the availability interface UI.
P	P	?	7.1	Run a free-busy report for the entire week.	VENDOR 3: unable to test because cannot add attendees
P	P	?	7.1.1	Verify two `FREEBUSY` periods for Monday, the second is `BUSY-TENTATIVE`.
P	P	?	7.1.2	Verify two `FREEBUSY` periods for Tuesday.
P	P	?	7.1.3	Verify four `FREEBUSY` periods for Wednesday, second and fourth are `BUSY-TENTATIVE` and one hour long.
P	P	?	7.1.4	Verify two `FREEBUSY` periods for Thursday.
P	P	?	7.1.5	Verify two `FREEBUSY` periods for Friday.
			8.	Scheduling
			Setup	Three user accounts user1 (role Organizer), user2 (role Attendee), user3 (role Attendee) provisioned with suitable principal properties for calendar home, inbox, outbox and user addresses.	Note 2 Vendor 2 server uses a virtual inbox, and attendee replies are not relayed back to the organizer. Vendor 5 does not make use of the inbox (events are updates automatically by the server); VENDOR 3: unable to test because cannot add attendees
P	N	?	8.1	Organizer (user1) sends nonrecurring message invite for Monday at 9am (1 hour) to each attendee. Verify that each attendee Inbox receives a copy of the invite.
F/N	N	?	8.2	Attendee (user2) accepts invite and sends back reply. Verify that reply is placed in Organizer Inbox.
P/N	N	?	8.3	Organizer (user1) updates invite with user2 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite.
F/N	N	?	8.4	Attendee (user3) accepts updated invite and sends back reply. Verify that reply is placed in Organizer Inbox.
P/N	N	?	8.5	Organizer (user1) updates invite with user3 accept state and resends invite. Verify that each attendee Inbox receives a copy of the new invite.	Vendor 2 passes inbox messages only for certain event updates.
F/N	N	?	8.6	Organizer (user1) cancels the invite. Verify that each attendee Inbox receives the cancellation.